一个好的app除了有吸引人的功能, 美丽的交互之外,性能也至关重要,作为一个技术人员,在这里当然只能讲技术了

一般app性能优化主要从一下几个方面入手,

对于app启动的优化,一般启动的时候设置一个主题/图片防止白屏或者延迟打开

如果启动页面不是一张图片,而且通过布局显示可以利用Splash加载部分图片先显示出来

在5.0后，增加了一个windowDrawsSystemBarBackgrounds属性，用来标志此窗口是否负责绘制系统栏背景，我们把它设成false，这样当它绘制windowBackground的时候，就会在NavigationBar之上。 因为这个属性是5.0以后才有的，所以需要新建values-v21文件夹，以便5.0以上的机器使用v21的Splash主题。

针对启动速度慢，需要尽可能减少Applicatio和启动页面的onCreate中所要做的事情,比如一些不重要的SDK延迟或者异步加载；部分第三方的初始化(如极光的初始化就很耗时)可以使用到的类异步加载；如果对于设备5.0以下,还要考虑multidex的优化.提高启动页面响应速度,一般点击app进入到首页不能超过3秒,如果超过3秒就应该要做处理了.

对于如何检测方法耗时,除了打印log,adb命令可以使用TraceView去看,后面我们会讲到

谈到UI流畅度，一般就是不要在主进程去做耗时的操作，提升UI的绘制速度,下面几点需要注意

不要在主线程进行网络访问/大文件的IO操作

绘制UI时，尽量减少绘制UI层次；减少不必要的view嵌套，减少重复绘制,可以用Hierarchy Viewer工具来检测，后面会详细讲；

当我们的布局是用的FrameLayout的时候，我们可以把它改成merge,可以避免自己的帧布局和系统的ContentFrameLayout帧布局重叠造成重复计算(measure和layout) 参考链接

提高显示速度,使用ViewStub：当加载的时候才会占用。不加载的时候就是隐藏的，仅仅占用位置。

在view层级相同的情况下，尽量使用 LinerLayout而不是RelativeLayout；因为RelativeLayout在测量的时候会测量二次，而LinerLayout测量一次，可以看下它们的源码；

删除控件中无用的属性;

布局复用.比如listView 布局复用

尽量避免过度绘制(overdraw)比如：背景经常容易造成过度绘制。由于我们布局设置了背景，同时用到的MaterialDesign的主题会默认给一个背景。这时应该把主题添加的背景去掉；还有移除 XML 中非必须的背景

自定义View优化。使用 canvas.clipRect()来帮助系统识别那些可见的区域，只有在这个区域内才会被绘制。也是避免过度绘制．

合理的刷新机制，尽量减少刷新次数，尽量避免后台有高的 CPU 线程运行，缩小刷新区域。

采用开销较低的布局:例如，您可能会发现，TableLayout 作为具有许多位置依赖项的更复杂的布局，可以提供相同的功能。在 Android 的 N 版本中，ConstraintLayout 类提供了与 RelativeLayout 类似的功能，但开销要低得多。

性能问题并不容易复现，也不好定位，下面介绍几个非常有用的工具分析卡顿

1.Profile GPU Rendering 在手机开发者模式下，有一个卡顿检测工具叫做：Profile GPU Rendering

2.Debug GPU overDraw过度绘制检测 在手机开发者模式下，有一个过度绘制检测工具叫做：Debug GPU overDraw,看图：

各个颜色代表的意义 Android 将按如下方式为界面元素着色，以确定过度绘制的次数： 真彩色：没有过度绘制 蓝色：过度绘制 1 次 绿色：过度绘制 2 次 粉色：过度绘制 3 次 红色：过度绘制 4 次或更多次

总之，尽量避免过度绘制,常见的就是设置了多个背景颜色造成

在开发的过程，如果方法不当的话，很容易造成内存泄漏，接下来，来说一下哪些情景容易出现内存泄漏。

单例中引用的上下文Context，引用了Activity中的Context, 这样会造成内存泄漏，要引用Application中的Context;()参考文章

尽量不要在Activity中使用非静态内部类，因为非静态内部类会隐式持有外部类实例的引用，如果使用静态内部类，将外部实例引用作为弱引用持有。

资源性对象未关闭。比如Cursor、File文件等，往往都用了一些缓冲，在不使用时，应该及时关闭它们。参考文章

注册对象未注销。比如事件注册后未注销，会导致观察者列表中维持着对象的引用。类的静态变量持有大数据对象。例如EventBus或者RxJava

使用MMKV替换SharePreference(就是以键值对形式存在xml文件中) 速度优势：写入速度是SharedPreferences的100倍左右。在主线程做IO存储 用mmkv一点问题都没有，不会出现卡顿情况,特别是在数据量比较大的时候，速度会一直保持在10ms以内 写入安全：通过 mmap 内存映射文件，提供一段可供随时写入的内存块，App 只管往里面写数据，由操作系统负责将内存回写到文件，不必担心 crash 导致数据丢失。 写入优化：SharedPreferences在本身数据量比较多的情况下，更新一个key-value时，会发生全量写入，意味着时间更长。mmkv避免了这种情况的出现。mmkv以增量方式进行写入 功能更全：支持多进程访问，支持数据加密。多线程安全写入 参考文件

非静态内部类的静态实例。参考文章

Handler临时性内存泄漏。如果Handler是非静态的，容易导致 Activity 或 Service 不会被回收,或者可以使用弱引用持有对Activity的引用。

容器中的对象没清理造成的内存泄漏。

WebView。WebView 存在着内存泄漏的问题，在应用中只要使用一次 WebView，内存就不会被释放掉。参考资料

除此之外，内存泄漏可监控, 推荐square公司开源的Leakcanary可以在发生内存泄漏时告警，并且生成 leak tarce 分析泄漏位置，同时可以提供 Dump 文件进行分析。

以下介绍几种内存分析工具

(1).显示可用和已用内存，并且以时间为维度实时反应内存分配和回收情况。 (2).快速判断应用程序的运行缓慢是否由于过度的内存回收导致。 (3).快速判断应用是否由于内存不足导致程序崩溃。

Memory Monitor 和 Heap Viewer 都可以很直观且实时地监控内存使用情况，还能发现内存问题，但发现内存问题后不能再进一步找到原因，或者发现一块异常内存，但不能区别是否正常，同时在发现问题后，也不能定位到具体的类和方法。这时就需要使用另一个内存分析工具 Allocation Tracker，进行更详细的分析， Allocation Tracker 可以分配跟踪记录应用程序的内存分配，并列出了它们的调用堆栈，可以查看所有对象内存分配的周期。

MAT 是一个快速，功能丰富的 Java Heap 分析工具，通过分析 Java 进程的内存快照 HPROF 分析，从众多的对象中分析，快速计算出在内存中对象占用的大小，查看哪些对象不能被垃圾收集器回收，并可以通过视图直观地查看可能造成这种结果的对象。

关于代码优化,有这么一个很好用的工具Android lint 在顶部菜单栏找到Analyze选项，在弹框中选中Inspect Code,或者对项目根双击弹出菜单弹框（windows下右键项目根目录），找到Analyze选项再选中Inspect Code选项

Correctness：不够完美的编码，比如硬编码、使用过时 API 等 Performance：对性能有影响的编码，比如：静态引用，循环引用等 Internationalization：国际化，直接使用汉字，没有使用资源引用等 Security：不安全的编码，比如在 WebView 中允许使用 JavaScriptInterface Remove All Unused Resources的选项,先全部清理,考虑反射机制,不能删除资源

Handler Reference leaks,当使用内部类（包括匿名类）来创建Handler的时候，Handler对象会隐式地持有一个外部类对象（通常是一个Activity）的引用（不然你怎么可能通过Handler来操作Activity中的View？）。而Handler通常会伴随着一个耗时的后台线程（例如从网络拉取图片）一起出现，这个后台线程在任务执行完毕（例如图片下载完毕）之后，通过消息机制通知Handler，然后Handler把图片更新到界面。然而，如果用户在网络请求过程中关闭了Activity，正常情况下，Activity不再被使用，它就有可能在GC检查时被回收掉，但由于这时线程尚未执行完，而该线程持有Handler的引用（不然它怎么发消息给Handler？），这个Handler又持有Activity的引用，就导致该Activity无法被回收（即内存泄露），直到网络请求结束（例如图片下载完毕）。另外，如果你执行了Handler的postDelayed()方法，该方法会将你的Handler装入一个Message，并把这条Message推到MessageQueue中，那么在你设定的delay到达之前，会有一条MessageQueue -> Message -> Handler -> Activity的链，导致你的Activity被持有引用而无法被回收。这个问题也是较常见的可能导致内存泄漏的问题，解决方法一般是通过弱引用持有对Activity的引用

Android代码优化——Layout Inspector 当您的布局在运行时构建而不是完全在XML布局中定义时，这尤其有用 Layout Inspector主要用分析布局的层级结构，减少不必要的层级，避免overdraw, 达到渲染优化的效果。Layout Inspector虽然界面不如HierarchyView直观，但是提供的信息也足够详细，分析布局层级绝对够用了。

Android代码优化---traceview使用 Debug.startMethodTracing(“hello”); Debug.stopMethodTracing(); TraceView 是 Android SDK 中内置的一个工具，它可以加载 trace 文件，用图形的形式展示代码的执行时间、次数及调用栈，便于我们分析。

trace 文件是 log 信息文件的一种，可以通过代码，Android Studio，或者 DDMS 生成。

使用luban压缩 是通过原生的bitmap.compress() 是1000倍,参考微信,手机拍照几M上传上去就几十KB

在移动设备中，电池的重要性不言而喻，没有电什么都干不成。对于操作系统和设备开发商来说，耗电优化一致没有停止，去追求更长的待机时间，而对于一款应用来说，并不是可以忽略电量使用问题，特别是那些被归为“电池杀手”的应用，最终的结果是被卸载。因此，应用开发者在实现需求的同时，需要尽量减少电量的消耗。 耗电的原因其实很多，这里我就讲一下几种优化方案，优化方案的反面就是他的原因了，几种优化方案如下：

合理的使用wack_lock锁，wake_lock锁主要是相对系统的休眠(这里就是为了省电，才做休)而言的，意思就是我的程序给CPU加了这个锁那系统就不会休眠了，这样做的目的是为了全力配合我们程序的运行。有的情况如果不这么做就会出现一些问题，比如微信等及时通讯的心跳包会在熄屏不久后停止网络访问等问题。所以微信里面是有大量使用到了wake_lock锁。这里有一篇关于wake_lock的使用，请查阅；

使用jobScheduler2，集中处理一些网络请求，有些不用很及时的处理可以放在充电的时候处理，比如，图片的处理，APP下载更新等等，这里有一篇关于jobScheduler的使用，请查阅；

计算优化，避开浮点运算等。

数据在网络上传输时，尽量压缩数据后再传输，建议用FlatBuffer序列化技术，这个比json效率高很多倍，不了解FlatBuffer，建议找资料学习一下，后面有时间的话，也会专门写关于FlatBuffer的文章．

在 Android5.0 以前，在应用中测试电量消耗比较麻烦，也不准确，5.0 之后专门引入了一个获取设备上电量消耗信息的 API:Battery Historian。Battery Historian 是是一款图形化数据分析工具，直观地展示出手机的电量消耗过程，通过输入电量分析文件，显示消耗情况；

随着功能不断增加，APP的包肯定不会断的变大，但应用的安装包越大，用户下载的门槛越高，特别是在移动网络情况下，用户在下载应用时，对安装包大小的要求更高，因此，减小安装包大小可以让更多用户愿意下载和体验产品。所以，我们还是要想办法去如何去优化，尽量减小app的安排包．

Android 应用的稳定性定义很宽泛，影响稳定性的原因很多，比如内存使用不合理、代码异常场景考虑不周全、代码逻辑不合理等，都会对应用的稳定性造成影响。其中最常见的两个场景是：Crash 和 ANR，这两个错误将会使得程序无法使用，比较常用的解决方式如下：

提高代码质量。比如开发期间的代码审核，看些代码设计逻辑，业务合理性等。

代码静态扫描工具。常见工具有Android Lint、Findbugs、Checkstyle、PMD等等。

Crash监控。把一些崩溃的信息，异常信息及时地记录下来，以便后续分析解决。

Crash上传机制。在Crash后，尽量先保存日志到本地，然后等下一次网络正常时再上传日志信息。

适当缓存，可让App看起来更快。 使用DiskLruCache。

其实app性能优化，不是一二天可以完成的，不断的提高开发的质量，发现了问题，就要及时的解决,不能推三拉四,这次就总结到这里,本人也是小白,希望能能够和大家一起学习.